home *** CD-ROM | disk | FTP | other *** search
/ BCI NET / BCI NET Dec 94.iso / archives / programming / blitzbasic / blitz-list200994.lha / blitz-list / 000495_blitz-list-request_Tue Jul 19 15:40:55 1994.msg < prev    next >
Internet Message Format  |  1994-09-20  |  4KB
  1. Received: from iconz.co.nz (iconz.co.nz [202.14.100.2]) by kantti.helsinki.fi (8.6.9/8.6.5) with SMTP id PAA03165 for <blitz-list@helsinki.fi>; Tue, 19 Jul 1994 15:40:30 +0300
  2. Received: (acid@localhost) by iconz.co.nz (8.6.6.Beta6/8.6.6.Beta6) id AAA14948; Wed, 20 Jul 1994 00:37:15 +1200
  3. Date: Wed, 20 Jul 1994 00:29:05 +1200 (NZST)
  4. From: Acid Software <acid@iconz.co.nz>
  5. Subject: Re: Bugs etc, and some display questions
  6. To: Martin Kift <M.H.Kift@swansea.ac.uk>
  7. cc: blitz-list@helsinki.fi
  8. In-Reply-To: <ED50824106@CE1.SWAN.AC.UK>
  9. Message-ID: <Pine.3.87.9407200004.F14408-0100000@iconz.co.nz>
  10. MIME-Version: 1.0
  11. Content-Type: TEXT/PLAIN; charset=US-ASCII
  12. X-Status: 
  13. Status: RO
  14.  
  15.  
  16.  
  17. On Tue, 19 Jul 1994, Martin Kift wrote:
  18.  
  19. > Hi all (and Acid too),
  20. > 
  21. > I have had various bug reports on my game, and while one or two of 
  22. > them are obvious bugs in my code, some of them at first appear to be 
  23. > either bugs or deficiencies in blitz itself. I may be wrong on one 
  24. > or two of them (so don't flame) me, I'm just trying to chase 
  25. > solutions to my problems, buts heres a few of them:
  26. > 
  27. > 1. My game does not boot from os3.1 (reported by other people, I 
  28. > can't test cos I only have 3.0). I think it causes a system crash. 
  29. > Also (as reported in other letters), running from DOpus causes a 
  30. > similar crash, maybe they are related.
  31.  
  32. oh god here we go again, another bloody rom, is that the one in CD32, we 
  33. have had no problems with cd32 ports of Blitz games so far, perhaps 
  34. bigger vwaits between closing files and entering Blitz mode is required?
  35.  
  36. > 
  37. > 2. I cannot find away to force open a pal screen screen when using 
  38. > slices, which is important when running on an ntsc system. Eventually 
  39. > I'd like to open a proper ntsc screen and support it properly, but in 
  40. > the meantime, I'd like to open a pal screen.
  41.  
  42. This is very tricky if you want to support workbench startup ie 1942 
  43. style monitors and take over the system type startups, the switch lib 
  44. looks at a location in graphics library to work out NTSC/PAL and hits 
  45. slices accordingly, can you not start your program by using an 
  46. openscreentags with some sort of pal config, hmm probably not, tell you 
  47. what I'll go and fix this problem instead of waffling on...
  48.  
  49. > 
  50. > Hmm, I thought there was more than that, maybe my memory is going 8)
  51. > 
  52. > Heres a couple of questions tho, maybe you can help me on these:
  53. > 
  54. > 1. How do I change rgb values in displays (the new display library, 
  55. > replacement for slices). Do I use the slice rgb command (doubt it?), 
  56. > or is there a command I've missed.
  57. > 
  58. At present you have to change them in the palette using agapalrgb and 
  59. then do a DisplayPalette
  60. > 2. When programming in the display library, I understand I create 
  61. > some copper lists (using InitCopList) and then call CreateDisplay. 
  62. > What happens if I want to dump that display and create another, 
  63. > probably based on a different coplist. (e.g. in my game, I go from a 
  64. > 2slice dp screen, to a full screen slice for the endscreens, etc, 
  65. > back to 2slice dp screen etc). 
  66. > 
  67. No, coplists do not take up very much memory at all. the great thing 
  68. about having them all allocated at the top of your program is that memory 
  69. is not fragmented, in skid for example we had all sorts of bitmaps 
  70. openning and closing, if you go and allocate a small piece of memory 
  71. anywhere between these calls you suddenly find you have not got enough 
  72. continuous memory for the big bitmap... hmmm, again sorry about the waffle...
  73. > Also, for this situation, do I have to initialise 3 cop lists (2 for 
  74. > the game screens and 1 for the endscreen, even tho this is not used 
  75. > until the end), since I understand this will take up a lot of memory.
  76. > With slices,, I can delete and create them as the game runs, but I 
  77. > can't see similar functions to do this under displaylibs.
  78. As I said adding and deleting slices completely fragments memory, with 
  79. coplists you just allocate which ones you need and they are there, 
  80. typical coplist will be less than 3K
  81.  > > Thanks for your time.
  82. > 
  83. > P.S. Any release dates available for BUM7? Any chances of fixes for 
  84. > the debugger (have you considered the possiblity of remote debugging, 
  85. > that would be beautiful!!), the sound/caches problem. Thanks.
  86. > 
  87. I'm aiming at Saturday
  88.  
  89. Simon
  90.